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Abstract 

The Tor network is a widely used system for anony¬ 
mous communication. However, Tor is known to be 
vulnerable to attackers who can observe traffic at both 
ends of the communication path. In this paper, we show 
that prior attacks are just the tip of the iceberg. We 
present a suite of new attacks, called Raptor, that can 
be launched by Autonomous Systems (ASes) to com¬ 
promise user anonymity. First, AS-level adversaries can 
exploit the asymmetric nature of Internet routing to in¬ 
crease the chance of observing at least one direction of 
user traffic at both ends of the communication. Second, 
AS-level adversaries can exploit natural churn in Inter¬ 
net routing to lie on the BGP paths for more users over 
time. Third, strategic adversaries can manipulate Inter¬ 
net routing via BGP hijacks (to discover the users using 
specific Tor guard nodes) and interceptions (to perform 
traffic analysis). We demonstrate the feasibility of Rap¬ 
tor attacks by analyzing historical BGP data and Tracer- 
oute data as well as performing real-world attacks on the 
live Tor network, while ensuring that we do not harm real 
users. In addition, we outline the design of two monitor¬ 
ing frameworks to counter these attacks: BGP monitor¬ 
ing to detect control-plane attacks, and Traceroute moni¬ 
toring to detect data-plane anomalies. Overall, our work 
motivates the design of anonymity systems that are aware 
of the dynamics of Internet routing. 

1 Introduction 

Anonymity systems aim to protect user identities from 
untrusted destinations and third parties on the Internet. 
Among all of them, the Tor network [25! is the most 
widely used. As of February 2015, the Tor network com¬ 
prises of 7,000 relays or proxies which together carry 
terabytes of traffic every day 0. Tor serves millions 
of users and is often publicized by political dissidents, 
whistle-blowers, law-enforcement, intelligence agencies, 


journalists, businesses and ordinary citizens concerned 
about the privacy of their online communications (5) . 

Along with anonymity, Tor aims to provide low la¬ 
tency and, as such, does not obfuscate packet timings 
or sizes. Consequently, an adversary who is able to ob¬ 
serve traffic on both segments of the Tor communication 
channel (i.e., between the server and the Tor network, 
and between the Tor network and the client) can corre¬ 
late packet sizes and packet timings to deanonymize Tor 
clients I45ll46l . 

There are essentially two ways for an adversary to 
gain visibility into Tor traffic, either by compromising 
(or owning enough) Tor relays or by manipulating the 
underlying network communications so as to put herself 
on the forwarding path for Tor traffic. Regarding net¬ 
work threats, large Autonomous Systems (ASes) such as 
Internet Service Providers (ISPs) can easily eavesdrop on 
a portion of all links, and observe any unencrypted infor¬ 
mation, packet headers, packet timing, and packet size. 
Recent declarations by Edward Snowden have confirmed 
that ASes poses a real threat. Among others, the NS A has 
a program called Marina which stores meta information 
about user communications for up to a year m, while 
the GCHQ has a program called Tempora that stores 
meta-information for 30 days and buffers data for three 
days l36l . Also, and maybe more importantly, it has been 
shown that Tor was targeted by such adversaries in col¬ 
lusion with ASes ifTOl IT2l ITTIl . 

In this paper, we present Raptor, a suite of novel traffic 
analysis attacks that deanonymize Tor users more effec¬ 
tively than previously thought possible. To do so, and 
unlike previous studies on AS-level adversaries [28, 26, 
m, Raptor leverages the dynamic aspects of the Inter¬ 
net routing protocol, i.e. the Border Gateway Protocol 
(BGP). 

Raptor attacks are composed of three individual at¬ 
tacks whose effects are compounded (Q. First, Raptor 
exploits the asymmetric nature of Internet routing: the 
BGP path from a sender to a receiver can be different 
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Table 1: This paper describes Raptor, a suite of previously unknown attacks on the Tor Network 


than the BGP path from the receiver to the sender. In¬ 
ternet routing asymmetry increases the chance of an AS- 
level adversary observing at least one direction of both 
communication endpoints, enabling a novel asymmetric 
traffic analysis attack. Second, Raptor exploits natural 
churn in Internet routing: BGP paths change over time 
due to link or router failures, setup of new Internet links 
or peering relationships, or changes in AS routing poli¬ 
cies. Changes in BGP paths allow ASes to observe ad¬ 
ditional Tor traffic, enabling them to deanonymize an in¬ 
creasing number of Tor clients over time. Third, Rap¬ 
tor exploits the inherent insecurity of Internet routing: 
strategic adversaries can manipulate Internet routing via 
BGP hijack and BGP interception attacks against the Tor 
network. These attacks enable the adversary to observe 
user communications, and to deanonymize clients via 
traffic analysis. 

Raptor attacks were briefly discussed in a preliminary 
and short workshop paper |[48l . In this paper, we go fur¬ 
ther by measuring the importance of the attacks using 
real-world Internet control- and data-plane data. We also 
demonstrate the attacks feasibility by performing them 
on the live Tor network —with success. No real Tor users 
were harmed in our experiments (Jj7]). Finally, we also 
describe efficient countermeasures to restore a good level 
of anonymity. To summarize, we make the following key 
contributions: 

Asymmetric Traffic Analysis and BGP Churn: Us¬ 
ing live experiments on the Tor network, we showed 
that Raptor’s asymmetric traffic analysis attacks can 
deanonymize a user with a 95% accuracy, without any 
false positives (Q. Using historical BGP and Tracer- 
oute data, we showed that by considering routing asym¬ 
metry and routing churn, the threat of AS-level attacks 
increases by 50% and 100%, respectively (Q. 

BGP Hijacks and Interceptions: We analyzed known 
BGP hijacks and interception attacks on the Internet and 
show multiple instances where Tor relays were among 
the target prefixes As an illustration, the recent Bit- 
coin Hijack attack (l] in 2014, as well as Indosat Hijack 
attacks mm in 2014 and 2011 involved multiple Tor re¬ 
lays. To demonstrate the feasibility of such attacks for 
the purpose of deanonymizing Tor clients, we success¬ 
fully performed an interception attack against a live Tor 
relay. Overall, we found that more than 90% of Tor re¬ 
lays are vulnerable to our attacks. 


Countermeasures: We present a comprehensive taxon¬ 
omy of countermeasures against Raptor attacks (^6]). In 
particular, we outline the design of a monitoring frame¬ 
work for the Tor network that aims to detect suspicious 
AS-level path changes towards Tor prefixes using both 
BGP and Traceroute monitoring. 

2 Raptor Attacks 

To communicate with a destination, Tor clients establish 
layered circuits through three subsequent Tor relays. The 
three relays are referred to as: entry (or guard ) for the 
first one, middle for the second one, and exit relay for 
the last one. To load balance its traffic, Tor clients se¬ 
lect relays with a probability that is proportional to their 
network capacity. Encryption is used to ensure that each 
relay learns the identity of only the previous hop and the 
next hop in the communications, and no single relay can 
link the client to the destination server. 

It is well known that if an attacker can observe the 
traffic from the destination server to the exit relay as well 
as from the entry relay to the client (or traffic from the 
client to the entry relay and from the exit relay to the 
destination server), then it can leverage correlation be¬ 
tween packet timing and sizes to infer the network iden¬ 
tities of clients and servers (end-to-end timing analysis). 
This timing analysis works even if the communication is 
encrypted. 

In the rest of the section, we present the three Raptor 
attacks and how they contrast to conventional symmetric 
traffic analysis. We start by discussing how seeing just 
one direction of the traffic for each segment (between 
the sender and the guard, and between the last relay and 
the destination) is sufficient for the adversary ( §2.1| ). We 
then explain how ASes can exploit natural BGP dynam¬ 
ics ( §2.2| ), or even launch active attacks ( §2.3| ), to com¬ 
promise the anonymity of Tor users. 

2.1 Asymmetric Traffic Analysis 

We propose asymmetric traffic analysis, a novel form of 
end-to-end timing analysis that allows AS-level adver¬ 
saries to compromise the anonymity of Tor users. Let 
us suppose that a Tor client is uploading a large file to a 
Web server. Conventional traffic analysis considers only 
one scenario where adversaries observe traffic from the 
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Figure 1: Asymmetric routing increases the power of 
AS-level adversaries. When considering forward traf¬ 
fic, i.e., client-to-entry and exit-to-destination flows, only 
AS 5 can compromise anonymity. When considering 
both forward and backward traffic though, AS3, AS4 
and AS5 can compromise anonymity. Our measurements 
confirm that asymmetric traffic analysis is feasible. 

client to the entry relay, and from the exit relay to the 
Web server (same direction as the flow of traffic 

However, Internet paths are often asymmetric: the 
path from the exit relay to the Web server may be dif¬ 
ferent than the path from the Web server to the exit relay. 
Thus it is possible that an adversary may not be able to 
observe the data traffic on the path from the exit relay 
to the server, but it observes the TCP acknowledgment 
traffic on the path from the server to the exit relay. 

We introduce an asymmetric traffic analysis attack that 
allows an adversary to deanonymize users as long as the 
adversary is able to observe any direction of the traffic , at 
both ends of the communication. Note that we can view 
the conventional end-to-end timing analysis as a special 
case of our attack, in which the adversary is able to ob¬ 
serve traffic at both ends of the anonymous path, and in 
the same direction as the flow of traffic. Routing asym¬ 
metry increases the number of ASes who can observe at 
least one direction of traffic at both communication end¬ 
points. We illustrate this scenario in Figure [I] 

More concretely, our attack is applicable to four sce¬ 
narios where an adversary observes (a) data traffic from 
the client to entry relay, and data traffic from exit relay to 
the server, or (b) data traffic from the client to entry re¬ 
lay, and TCP acknowledgment traffic from the server to 
exit relay, or (c) TCP acknowledgment traffic from guard 
relay to the client, and data traffic from exit relay to the 
server, or (d) TCP acknowledgment traffic from guard re¬ 
lay to the client, and TCP acknowledgment traffic from 
the server to the exit relay. 

A key hurdle in asymmetric traffic correlation is that 
TCP acknowledgments are cumulative, and there is not 
a one-to-one correspondence between data packets and 

1 If the traffic is flowing from the server to the client, then end-to- 
end timing analysis considers a scenario where the adversary observes 
traffic from the Web server to the exit relay and from the entry relay to 
the client. 


the TCP acknowledgment packets. We overcome this 
hurdle by observing that Tor (and other anonymity sys¬ 
tems) use SSL/TLS for encryption, which leaves the TCP 
header unencrypted. Our attack inspects TCP headers in 
the observed traffic to retrieve the TCP sequence number 
field and TCP acknowledgment number field, and ana¬ 
lyzes the correlation between these fields of both ends 
over time. Our experimental results in Section [3] show 
the feasibility of asymmetric traffic analysis, with a de¬ 
tection accuracy of 95%. Furthermore, asymmetric traf¬ 
fic analysis can be combined with other Raptor attacks, 
such as exploiting natural churn and BGP interception 
attack, which we discuss next. 

2.2 Natural Churn 

client-to-entry exit-to-server 

connection connection dest dest 


client exit client exit 

Figure 2: BGP chum increases the number of ASes that 
can deanonymize Tor traffic. Initially, only AS5 can 
deanonymize the client, seeing both direction of the traf¬ 
fic (left). After the failure of link (AS4, AS5), both AS5 
and AS3 can deanonymize Tor traffic (right). 

When users communicate with recipients over multi¬ 
ple time instances, then there is a potential for compro¬ 
mise of anonymity at every communication instance [49 , 
42]. Thus anonymity can degrade over time. Tor consid¬ 
ers this threat from the perspective of adversarial relays 
(but not adversarial ASes).Tor clients use a fixed entry 
relay (guard relay) for a period of time (Dingledine et al. 
recommend 9 months [24 J) to mitigate this threat with 
respect to adversarial relays. We note that the threat of 
AS-level adversaries still persists, because even though 
the entry relay is fixed, the set of ASes on the path be¬ 
tween the client and the guard relay may change over 
time. Next, we discuss such attacks that rely on natural 
churn in BGP paths. 

The underlying Internet paths between a client and 
guard relay vary over time due to changes in the phys¬ 
ical topology ( e.g ., failures, recoveries, and the rollout 
of new routers and links) and AS-level routing policies 
(e.g., traffic engineering and new business relationships). 
These changes give a malicious AS surveillance power 
that increases over time. For example, AS 3 in Figure [2] 
does not lie on the original path from the exit to the des- 
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tination, but a BGP routing change can put AS 3 on the 
path, allowing it to perform traffic analysis. 

In Section |4| we show that the surveillance capability 
of an AS-level adversary can increase up to 50% when 
considering BGP chum over a period of one month. 

2.3 BGP Hijack 

So far, we discussed Raptor attacks that were pas¬ 
sive. Strategic AS-level adversaries are also capable of 
launching active attacks, that deviate from honest routing 
behavior. Internet routing is vulnerable to attacks which 
enable an AS to manipulate inter-domain routing by ad¬ 
vertising incorrect BGP control messages. While these 
attacks are well known in the networking community, we 
are the first to apply these attacks to anonymity systems 
such as Tor. 

AS-level adversaries can hijack an IP prefix EO by 
advertising the prefix as its own. The attack causes a 
fraction of Internet traffic destined to the prefix to be 
captured by the adversary. Tor relay nodes can ob¬ 
serve a large amount of client traffic. For example, a 
Tor guard relay observes information about client IP ad¬ 
dresses. Thus, the IP prefixes corresponding to Tor guard 
relays presents an attractive target for BGP hijack. 

As a concrete attack example, we consider a scenario 
where an AS-level adversary aims to deanonymize the 
user associated with a connection to a sensitive Web 
server (say a whistleblowing website). The adversary can 
first use existing attacks on the Tor network to uncover 
the identity of the client’s guard relay (39] [37] [31] 42). 
Next, the adversary can launch a BGP hijack attack 
against the Tor relay. This allows the adversary to see 
traffic destined to the guard relay. BGP hijack thus en¬ 
ables an adversary to leam the set of all client IP ad¬ 
dresses (anonymity set) associated with a guard relay 
(and the target connection to the sensitive Web server). 

We note that in a prefix-hijack attack, the captured 
traffic is blackholed, and the client’s connection to the 
guard is eventually dropped. Thus, it may not be pos¬ 
sible to perform fine-grained traffic analysis to infer the 
tme client identity from this anonymity set. However, the 
identification of a reduced anonymity set (as opposed to 
the entire set of Tor users) is already a significant amount 
of information leakage, and can be combined with other 
contextual information to break user anonymity HE In 
Section[5] we uncover several real-world BGP hijack at- 
tacks in which Tor relays were among the target prefixes. 

2.4 BGP Interception 

Our BGP hijack attack discussed above allows adver¬ 
saries to capture traffic destined towards a target Tor 
prefix, but the captured traffic is blackholed, resulting 



Figure 3: BGP interception attack enables ASes to selec¬ 
tively put themselves on some path. Here, AS3 only sees 
traffic between the client and the entry relay (left). By 
intercepting the prefix containing the exit relay (right), 
AS 3 also sees traffic towards the exit relay, enabling it to 
deanonymize the Tor communication. 


in the connecting being dropped. Next, we discuss a 
more sophisticated routing attack called BGP intercep¬ 
tion attack (El, that allows adversaries to perform exact 
deanonymization of Tor users. 

A prefix interception attack allows the malicious AS to 
become an intermediate AS in the path towards the guard 
relay, i.e., after interception, the traffic is routed back to 
the actual guard relay. Such an interception attack al¬ 
lows the connection to be kept alive, enabling the ma¬ 
licious AS to exactly deanonymize the client via asym¬ 
metric traffic analysis. 

Similar to the previous discussion, let us consider an 
adversary trying to deanonymize the user connecting to 
a sensitive website (the adversary already sees the traf¬ 
fic towards the website). The adversary can first uncover 
the identity of the guard relay using existing attacks [ 391 
(as before), and then launch a prefix interception attack 
against the guard relay. Since the adversary routes the 
traffic back to the guard relay, the client’s connection is 
kept alive, allowing the adversary to launch asymmetric 
traffic correlation attacks. Note that in contrast to BGP 
hijack attacks, BGP interception attacks can perform ex¬ 
act deanonymization of Tor clients. 

These attacks enable malicious ASes to deanonymize 
user identity corresponding to a monitored target connec¬ 
tion. Similarly, ASes that already see the client’s traffic 
to its guard can position themselves to observe the traffic 
between the server and the exit relay by launching inter¬ 
ception attacks against exit relays. Figure [3] illustrates 
this attack scenario. 

Finally, we note that a remote adversary can launch in¬ 
terception attacks against both guard relays and exit re¬ 
lays simultaneously, to perform general surveillance of 
the Tor network. In Section [5] we demonstrate a real- 
world BGP interception attack against a live Tor relay by 
collaborating with autonomous system operators. 
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3 Asymmetric Traffic Analysis 


In this section, we experimentally show that asymmet¬ 
ric traffic analysis attacks are feasible. We use the live 
Tor network for our experiments. To protect the safety 
of real Tor users, we generate our own traffic through the 
Tor network. Our goal is to investigate the accuracy of 
asymmetric traffic analysis in deanonymizing our gener¬ 
ated traffic. 

Experimental Setup: In order to generate our own 
traffic through the live Tor network, we use Planet- 
Lab nodes as clients and Web servers. PlanetLab is an 
open platform for networking research, that provides ac¬ 
cess to hundreds of geographically distributed machines. 
We randomly pick 100 machines on PlanetLab, located 
across United States, Europe, and Asia. We installed Tor 
clients on 50 of those machines, and used the Privoxy 
tool (www.privoxy.org) to configure wget requests to 
tunnel over Tor. The remaining 50 machines were setup 
to be Web servers, each containing a 100 MB image file. 

We use the default Tor configuration on the 50 client 
machines. We launch wget requests on the 50 clients 
at the same time, each requesting a 100MB image file 
from one of the 50 web servers, respectively. We use 
tcpdump to capture data for 300 seconds at the clients 
and the servers during this process. 

Asymmetric correlation analysis: In each packet trace, 
we first extract the TCP sequence number and TCP ac¬ 
knowledgment number fields in the TCP header. Us¬ 
ing the TCP sequence and acknowledgment numbers, we 
next compute the number of transmitted data bytes per 
unit time. For each pair of observed traces, we com¬ 
pute the correlation between the vector of transmitted 
data bytes over time. For our analysis, we use the Spear¬ 
man’s rank correlation coefficient (other correlation met¬ 
rics could also be applicable). For each client, our asym¬ 
metric traffic analysis attack selects the server trace with 
the highest correlation as the best match. 

Results: Figure [4] illustrates our asymmetric analysis 
computed between a client server pair that is commu¬ 
nicating. We can see high correlation in all four ob¬ 
servation scenarios discussed in Section 2. Figure [5] il¬ 
lustrates our asymmetric analysis computed between a 
client server pair that is not communicating with each 
other. We can see that incorrectly matched pairs have 
poor correlation in all four observation scenarios. Fig¬ 
ure [6] illustrates the detection accuracy rate grows as the 
duration of attack increases, especially in the first 30 sec¬ 
onds. 

We computed the detection accuracy of our asymmet¬ 
ric traffic analysis attacks in all four scenarios after 300 
seconds (by selecting the highest correlated pair), and 
obtained an average accuracy of 95% (Table [2]). The er¬ 
ror matches are all false negatives, for which the client 




(a) Client: ACK, Server: ACK (b) Client: ACK, Server: Data 



(c) Client: Data, Server: ACK (d) Client: Data, Server: Data 

Figure 4: Asymmetric traffic analysis shows high corre¬ 
lation between a matched client/server pair 


has insignificant correlation coefficients with all servers, 
so it fails to be matched to any servers. We did not ob¬ 
serve any false positives in our results. 



Client ACK/ 

Server ACK 

Client ACK/ 

Server Data 

Client Data/ 

Server ACK 

Client Data/ 

Server Data 

Overall 

96% 

94% 

96% 

94% 

False negative 

4% 

6% 

4% 

6% 

False positive 

0% 

0% 

0% 

0% 


Table 2: Asymmetric traffic analysis accuracy rate 


In addition to the actual observed error rate above, we 
also performed a statistical tests to compute the 95% con¬ 
fidence interval on our error rate, given our sample size 
of 50 client machines and 50 server machines. Tabled 
illustrates the confidence intervals on our error rates. 



Client ACK/ 

Client ACK/ 

Client Data/ 

Client Data/ 


Server ACK 

Server Data 

Server ACK 

Server Data 

False negative 

0.48% - 

1.25% - 

0.48% - 

1.25% - 

13.71% 

16.54% 

13.71% 

16.54% 

False positive 

0%- 

0%- 

0%- 

0%- 

0.15% 

0.15% 

0.15% 

0.15% 


Table 3: Asymmetric traffic analysis error rate confi¬ 
dence interval 


4 Natural Churn 

In this section, we study and evaluate how routing dy¬ 
namics, or chum, increase the power of AS-level adver¬ 
saries in anonymity systems such as Tor. We start with 
an exhaustive control-plane analysis using collected BGP 


5 







































(a) Client: ACK, Server: ACK (b) Client: ACK, Server: Data 




(c) Client: Data, Server: ACK (d) Client: Data, Server: Data 


Figure 5: Asymmetric traffic analysis shows low corre¬ 
lation between an unmatched client/server pair 



Figure 6: The accuracy of the attack quickly increases 
with time, reaching 80% within a minute, 95% after five 
minutes. 


data ( §4.1| ). Our results show that churn can increase the 
amount of compromised Tor circuits by up to 50% over 
a period of one month. We then confirmed our results by 
performing targeted data-plane measurements on the Tor 
network ( §4.2| ). Again, churn significantly increased the 
percentage of vulnerable Tor circuits, nearly tripling it. 

4.1 Control-plane Evaluation 

We quantified the impact of churn by measuring how it 
increased the probability of a single AS (say AS X ) to 
end up simultaneously on the path between a client and 
a guard relay and on the path between a destination and 
an exit relay. When this happens, we considered AS X 
as (potentially) compromising for the pair (client, desti¬ 
nation) using the corresponding Tor circuit. Observe that 
our analysis leverages asymmetric traffic analysis (Q as 
it only requires X to be on-path for two publicly-known 
prefixes, covering the guard and the exit relay. 

Datasets We collected 612+ million BGP updates per¬ 


taining to 550,000 IP prefixes collected by six RIPE- 
maintained BGP Looking Glass (rrcOO, rrcOl, rrc03, 
rrc04 , rrc 11 , rrc 14) 13 in January 2015 over 250+ BGP 
sessions. We processed the dataset to remove any arti¬ 
facts caused by session resets |[20l . In parallel, we also 
collected Tor-related data (IP address, flags and band¬ 
width) of about 6755 Tor relays active during the same 
period of time d Among all Tor relays, 1459 (resp. 
1182) of them were listed as guards (resp. exits) and 338 
relays were listed as both guard and exit. 

We considered each BGP session as a proxy for Tor 
clients and destinations. Note that analysis implicitly ac¬ 
counts for any Internet host reachable directly or indi¬ 
rectly through these BGP sessions. Our dataset contains 
sessions belonging to major Internet transit providers 
such as Level-3, ATT, NTT, etc. that provide transit to 
millions of hosts. 

Static baseline. We computed a static baseline by con¬ 
sidering the amount of compromising ASes at the be¬ 
ginning of our dataset, without considering any updates. 
On each BGP session su we computed and maintained 
the routing table used to forward Tor traffic by consid¬ 
ering all the BGP announcements and withdrawals re¬ 
ceived over Si. More precisely, we kept track of the most- 
specific routing table entry that was used to forward traf¬ 
fic to any Tor guard or exit relays. We refer to those as 
Tor prefixes. In this context, a routing table entry for a 
relay r is a five-tuple (ti,tf,p,e,L) composed of: i) the 
initial time ti at which the entry started to be used by 
the router for forwarding traffic to r; ii) the final time tf 
at which the entry stopped to be used by the router; in) 
the corresponding IP prefix p\ iv) a boolean e denoting 
whether the r is an entry or an exit relay; and v) the list 
of all the ASes L that will see the traffic en-route to reach 
r (; i.e ., the AS-PATH). 


“on-path” AS 



sources guard exit destinations 

(BGP sessions) relays relays (BGP sessions) 


Figure 7: Control-plane evaluation setup 

Using the routing-table data, we accounted, for each 
AS X, the number of pairs (( Si , gi ), (sj, ej)) for which it 
appeared simultaneously in the AS-PATH. Here, Si (resp. 
Sj) refers to a client (resp. destination) session, while gi 
(resp. ej) refers to a Tor guard (resp. exit) relay. To 
ensure meaningful results, we only considered cases in 
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which Si and sj are in different ASes to ensure enough 
diversity in the paths seen. As illustration, in Fig. [7J 
ASx is a compromising AS for the pair ((s\, g 1 ), (S2, 
^ 2 )), meaning it can deanonymize any clients connected 
beyond s\ and exchanging data with a destination con¬ 
nected beyond S2 which uses g\ (resp. e 2 ) as a guard 
(resp. exit) relay. 




% of compromised TOR circuits per (src,dst) pairs when considering churn and without 


(a) Static baseline (b) Churn-induced increase 

Figure 8 : Without considering churn, more than 5% of 
all the possible Tor circuits are compromised by at least 
one AS in 20% of the cases (left). The amount of com¬ 
promised circuits increase for the majority of the (src, 
dest) pairs (60%) when considering chum, by up to 50% 
in 20 % of the cases (right). 

Fig.[ 8 a]depicts the percentage of compromised Tor cir¬ 
cuits for each source and destination as a Complemen¬ 
tary Cumulative Distribution Function (CCDF). A point 
(x,y) on the curve means that x% of all Tor circuits, i.e. 
(guard,exit) pairs, are compromised for at least y% 
of all the (src,dst) pairs. We see that, for 50% of all 
the (src,dst) pairs, at least 0.75% of the Tor circuits 
are compromised by at least one AS. This number grows 
to 6 % and 13% of the Tor circuits considering the 75 th - 
and 95 th -percentile, respectively. 

Measuring the effect of churn. We computed the num¬ 
ber of extra Tor circuits that got compromised by at least 
one AS over one month. To be fair, we only considered a 
Tor circuit as compromised if it crossed the same AS for 
at least 30 seconds as it is unlikely that a time-correlation 
attack can be performed in shorter timescale. Fig. [ 8 b] 
plots the ratio between the amount of compromised Tor 
circuits for each (src, dst) pair at the end of the month 
with respect to the static baseline amount. We see that 
churn significantly increases the probability of compro¬ 
mise. Indeed, the amount of compromised circuits in¬ 
crease for 60% of the (src, dst). The increase reaches 
50% (ratio of 1.5) in 20% of the cases. 

In addition to increasing the number of compro¬ 
mised Tor circuits, churn also increases the number of 


compromisable (src,dst) pairs. Indeed, while 5593 
(src,dst) pairs could be compromised without up¬ 
dates, that number increased to 5754 pairs when consid¬ 
ering updates (an augmentation of nearly 3%). 


Name 

ASN 

Tor circuits (%) seen 

Country 

NTT 

2914 

91 

US 

IIJ 

2497 

91 

Japan 

BroadbandONE 

19151 

91 

US 

Inet7 

13030 

91 

CH 

Level3 

3356 

88 

US 

Tinet 

3257 

86 

DE 

Cogent 

174 

63 

US 

Level3/GBLX 

3549 

58 

US 

TATA AMERICA 

6453 

53 

US 

TeliaSonera 

1299 

50 

SWE 


Table 4: A few well-established ASes simultaneously see 
some traffic for up to 90% of all (entry, exit) relays pairs. 

Few powerful ASes see some traffic for a large ma¬ 
jority of the Tor circuits. Due to their central position 
in the Internet, a few ASes naturally tend to see a lot of 
Tor traffic crossing them. To account for this effect, we 
compute how many Tor circuits crossed each AS from 
at least one (src,dst) pair. The top 10 ASes in terms 
of compromised circuits are listed in Table [4| Large net¬ 
works such as NTT or Level3 are able to see Tor traffic 
for up to 90% of Tor circuits. 

4.2 Data-plane Evaluation 

Next, we aim to quantify the impact of churn using data- 
plane information collected via trace route. 

Datasets We ran traceroute between 70 RIPE Atlas 
probes 0 to measure the actual forwarding path taken 
by packets entering and exiting the Tor network. We se¬ 
lected one probe in 70 different ASes, split in the follow¬ 
ing four sets: 

• Si : 10 ASes that contain the most Tor clients (351 ; 

• S 2 : 25 ASes that cumulatively contained ~50% of all 
guard relay bandwidth; 

• S 3 : 25 ASes that cumulatively contained ~50% of all 
exit relay bandwidth; 

• S 4 : 10 ASes that contain the most Tor destina¬ 
tions ED 

We then ran daily traceroutes over a 3 weeks period be¬ 
tween all probes in Si towards all probes in S 2 (and vice- 
versa), measuring the forwarding paths P\ between Tor 
clients and guard relays, and the paths P 2 between guard 
relays and Tor clients. Similarly, we measured the for¬ 
warding paths P 3 between exit relays and Tor destina¬ 
tions, and the paths P 4 between Tor destinations and exit 
relays. Overall, we measured 10x25x25x 10 = 62500 
possible Tor circuits. 
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Time (Day) 


Figure 9: Percentage of Tor circuits vulnerable to an AS 
level adversary 


% relays 

% bw 

# pfx 

Name 

ASN 

10.5 

23 

11.80 

OVH 

16276 

6.30 

13 

6.68 

Hetzner 

24940 

4.78 

7 

10.52 

Online.net 

12876 

3.04 

4 

2.58 

Wedos 

197019 

2.04 

14 

4.27 

Leaseweb 

16265 

1.69 

9 

3.86 

PlusServer 

8972 

28.35 

70 

39.71 




Table 5: 6 ASes and 70 prefixes host ~30% of all Tor 
guard and exit relays as well as -40% of the entire Tor 
network bandwidth. As such, these constitute extremely 
attractive targets for hijacks and interceptions attacks. 


Churn nearly tripled the amount of vulnerable Tor 
circuits. If we use conventional methodology and only 
look for common ASes between P\ and P 3 , we found 
12.8% of Tor circuits to be vulnerable on the first day 
of the experiment (red line in Fig. [9]). In comparison, 
if we also consider asymmetric paths (i.e., also look for 
common ASes between P\ and P 4 , P 2 and P 3 , and P 2 and 
P 4 ), the percentage of vulnerable Tor circuits nearly dou¬ 
bled to 21.3% on the first day (blue line in Fig. [9]), and 
nearly tripled to 31.8% at the end of the three week pe¬ 
riod (green line in Fig. [9]). 


5 BGP Attacks: Hijack and Interception 


In this section, we study and evaluate the feasibility 
of BGP hijack and interception attacks on the Tor net¬ 
work. First, we show that Tor relays tend to be concen¬ 
trated within few ASes and IP prefixes—making those 
highly attractive targets for hijack and interception at¬ 
tacks ( 0 - Second, we show that, in several real- 
world BGP hijack attacks, Tor relays were among the 
target prefixes ( §5.2| ). Third, we perform a real-world 
BGP interception attack against a live Tor guard relay, 
with success , to demonstrate the ability to accurately 


deanonymize Tor clients ({53 ) 


width in the entire Tor network (see Table As such, 
these few prefixes constitute extremely attractive targets. 

5.2 Known Prefix Hijacking Attacks 

While there have been numerous well-documented BGP 
prefix hijacks and interceptions, it was unknown whether 
Tor traffic was intercepted or not. To this extent, we stud¬ 
ied occurrences of well-known prefix hijacks and looked 
for leaked prefixes covering at least a Tor relay. To do so, 
we gathered BGP updates from Routeviews 0 around 
the time of each attack and filtered out the ones related to 
Tor prefixes. Overall, we found that three well-known hi¬ 
jacks affected Tor relays: two separate incidents involv¬ 
ing one of Indonesia’s largest telecommunication net¬ 
works, Indosat, as well as one malicious hijack attack 
whose goal was to steal Bitcoins. 


Event 

# hijacked 
relays 

# hijacked 
guards 

# hijacked 
exits 

Indosat 2011 

5 (0.24%) 

1 (0.15%) 

4 (0.44%) 

Indosat 2014 

44 (0.80%) 

38 (1.80%) 

17(1.65%) 


Table 6 : Summary statistics for known Indosat prefix hi¬ 
jacking events. 


5.1 Tor relays concentration 

The amount of Tor traffic attracted by a hijack or an in¬ 
terception attack depends on the number of relays that 
lie within the corresponding prefix. As such, prefixes 
and ASes that host many relays of high bandwidth are an 
interesting targets for attackers. To evaluate how vulner¬ 
able the Tor network was to hijack and interceptions at¬ 
tacks, we computed the number of ASes present in each 
AS and in each BGP prefix. Surprisingly, close to 30% 
of all relays are hosted in only 6 ASes and 70 prefixes. 
Together, these relays represent almost 40% of the band- 


Indosat 2011. On January 14th, 2011, Indosat (AS4761) 
originated 2,800 new prefixes, which covered 824 differ¬ 
ent ASes 0 . 7 of these prefixes affected the Tor net¬ 
work by covering 5 of the Tor relays. As discussed in 
Section [2| Indosat could potentially have learned infor¬ 
mation about the client IP addresses associated with each 
of the guard relays (reduced anonymity set). 

Indosat 2014. On April 3, 2014, Indosat originated 
417,038 new prefixes; it usually originates 300 pre¬ 
fixes 0 . This compromised 44 Tor relays, 38 of which 
were guard relays and 17 of which were exit relays (11 
hijacked relays were both guards and exits). Table [6] 
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Figure 10: Transit Portal setup 


Figure 11: ISI performing interception attack 


shows the summary statistics of both Indosat hijacking 
incidents. 

Canadian Bitcoin 2014. From February 2014 to 
May 2014, an attacker compromised 51 networks at 
19 different ISPs, and resulted in the theft of ap¬ 
proximately $83,000 in Bitcoin (2. We found that 
198.245.63.0/24 and 162.243.142.0/24 were hijacked, 
and contained a Tor relay, 198.245.63.228. AS 16276 
(OVH) owns 198.245.63.0/24, but this prefix was hi¬ 
jacked by AS21548 (MTO Telecom). The Tor relay that 
consequently was hijacked, 198.245.63.228, was a guard 
relay located in Montreal, Quebec. 

While we do not make any claims about the intent of 
the above hijacking ASes, our analysis shows the exis¬ 
tential threat of real-world routing attacks on the Tor net¬ 
work. Furthermore, the fact that the Tor and the research 
community missed noticing the presence of Tor relays 
among the hijacked prefixes is surprising. 

5.3 BGP Prefix Interception Attack Exper¬ 
iment 

Methodology and setup. We now demonstrate the feasi¬ 
bility of the interception attack by performing one, with 
success, on the live Tor network. For that, we set up a 
machine to run as a Tor guard relay and made it reachable 
to the Internet by announcing a /23 prefix in BGP using 
Transit Portal (TP) lt43il . TP enables virtual ASes to es¬ 
tablish full BGP connectivity with the rest of the Internet 
by proxying their announcements via dozens of world¬ 
wide deployments. Next, we configure the 50 Tor clients 
in PlanetLab to use our Tor guard relay as the entry relay 
to reach 50 web servers, also hosted in PlanetLab. 

In order to perform the BGP prefix interception attack, 
we used two TP deployments (GATECH and ISI), located 
in different ASes. GATECH TP served the purpose of the 
“good” AS through which Tor traffic is normally routed, 
while ISI TP served as the “malicious” AS which per¬ 


formed the interception attack. We connected the two 
TPs to our Tor relay machine via VPN tunnels. First, in 
order for our Tor guard relay (running on 184.164. x. x) 
to be reachable, we advertised 184.164. x. x/23 via the 
GATECH TP, so that traffic destined for IP addresses 
within that range will be routed, first to the GATECH 
TP, and then sent to our machine via the corresponding 
tunnel. We illustrate our setup in Fig. |TT)| 

Next, We advertise BGP prefix 184.164.x. x/24 via 
the ISI TP, which constitutes a more-specific prefix at¬ 
tack against the original announcement announced by the 
GATECH TP. Thus, after the new BGP prefix announce¬ 
ment gets propagated through the internet, Tor client traf¬ 
fic that is destined for our guard will be sent to ISI in¬ 
stead. Since we configured the ISI TP to forward traffic 
to our guard machine, the Tor relay can still receive the 
traffic and keep the Tor connection alive after the attack. 


We illustrate the interception attack model in Fig. 11 


Our setup constitutes a BGP interception attack. Ini¬ 
tially, traffic is routed via GATECH and arrives at our Tor 
relay machine via GATECH tunnel. After the attack hap¬ 
pens, traffic drains from GATECH tunnel and gets routed 
via ISI, and thus comes to our Tor relay machine via ISI 
tunnel instead. Since the traffic still arrives at the relay 
machine, it is an interception attack and the connection 
does not get interrupted. We use tcpdump on our relay 
machine, listening to ISI tunnel, to capture client TCP ac¬ 
knowledgment traffic coming from that tunnel, which is 
exactly the data that an adversary would get from launch¬ 
ing such an interception attack. 

In the experiment, we first launch simultaneous HTTP 
requests using wget at the 50 Tor clients for the 100MB 
file at the 50 web servers. Then, 20 seconds after launch¬ 
ing the wget requests, we start announcing the more- 
specific prefix via ISI. We use tcpdump listening to ISI 
tunnel to capture TCP acknowledgment traffic sent from 
the Tor clients during the interception attack. We also use 
tcpdump to capture traffic at the web servers during the 
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(a) Traffic Flow via GATECH (b) Traffic Flow via ISI 
Figure 12: Traffic Flow During the Experiment 

whole process. Finally, 300 seconds after launching the 
attack, we send a withdrawal message via the ISI TP, so 
the traffic will be routed via GATECH again as normal. 
Our interception attack successfully deanonymized 
Tor sources with a 90% accuracy rate. In Fig. [I2j we 
plot the Tor traffic flow captured on our relay machine 
from both GATECH tunnel and ISI tunnel. We can see 
that all traffic is routed via GATECH at the beginning. 
At t — 20s, ISI starts advertising a more specific /24 pre¬ 
fix, which takes approximately 35 seconds for it to be 
propagated through the internet and drain the traffic from 
GATECH. At t = 55s, traffic starts showing up via ISI, 
and GATECH does not receive traffic any more. Then, 
at t — 300s, ISI withdraws the IP prefix announcement, 
which takes approximately 22 seconds for the traffic to 
appear back on GATECH again. During this interception 
process, the connection stays alive. 

The captured data from ISI tunnel is client TCP ac¬ 
knowledgment traffic. Thus, we will employ our Asym¬ 
metric Traffic Analysis approach, described in Section[3j 
to do the correlation analysis to deanonymize users’ 
identity. We achieve 90% accuracy rate (see Table [ 7 ]). 


Accuracy 

False 

False 

Rate 

Negative 

Positive 

Client ACK/Server ACK 90% 

8% 

2% 


Table 7: Asymmetric Traffic Analysis accuracy rate 

Fig.[l3]shows an example of a client with its correlated 
server and an uncorrelated server, respectively. Note that 
the time shown on the graph has been adjusted according 
to the time that traffic starts showing via ISI. 

The detection accuracy rate in the interception attack 
case decreases from the average 95% in static asymmet¬ 
ric traffic analysis to 90%. One main reason is that we 
configure all 50 Tor clients to connect to the same Tor 
guard relay, which leads to significantly higher probabil¬ 
ity that many of them will share the same Tor exit relay 
(especially those clients which are in the same AS) as 
well, and as a result, their bandwidths are highly likely 
to be similar. And also, all the clients start requesting 
files from the web servers at the same time, so the band- 




(a) Client & Correlated Server (b) Client & Uncorrelated Server 
Figure 13: Client ACK versus Server ACK analysis 



prefix length 

Figure 14: >90% of BGP prefixes hosting relays are 
shorter than /24, making them vulnerable to our attack. 

width they could achieve will be limited by the guard and 
the exit relay, which leads to similar bandwidths due to 
the guard/exit bottleneck. However, this scenario is an 
extreme and very unlikely case in real Tor connections. 
With fewer clients connecting to the same Tor guard re¬ 
lay at the same time, the accuracy of the asymmetric traf¬ 
fic analysis should be higher. 

The vast majority of Tor relays are vulnerable to our 
attacks. Technically, only prefixes shorter than /24 can 
be hijacked globally with a more-specific prefix attack 
as longer prefixes tend to be filtered by default by many 
ISPs. To make sure of the feasibility of our attack, we 
computed the prefix length distribution of Tor prefixes 
(see Figfl4]). We can see that more than 90% of BGP pre¬ 
fixes hosting relays have prefix length shorter than /24, 
making them directly vulnerable to a more-specific pre¬ 
fix attack such as ours. 


6 Countermeasures Sketch 

In this section, we first describe a taxonomy of counter¬ 
measures against Raptor attacks. Second, we describe 
a general approach for AS-aware anonymous communi¬ 
cation in which Tor clients are aware of the dynamics 
of Internet routing. Finally, we describe exploratory ap¬ 
proaches for detecting and preventing BGP hijack and 
interception attacks against Tor. 
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6.1 Countermeasure Taxonomy 


6.3 Mitigating Routing Attacks in Tor 


There are two main categories of countermeasures: (a) 
approaches that reduce the chance of an AS-level adver¬ 
sary observing both ends of the anonymous communica¬ 
tion, and (b) approaches that aim to mitigate correlation 
attacks even when an adversary observes both ends of 
the anonymous communication. Figure [15] illustrates the 
design space of potential countermeasures against Rap¬ 
tor attacks. In this work, we advocate the former line of 
defense - namely, to monitor both routing control-plane 
and data-plane, and to strategically select Tor relays that 
minimize the chance of compromise ( §6.2| ). We also ad¬ 
vocate defenses that aim to detect and prevent routing at¬ 
tacks (£6.3). We do not focus on the class of approaches 
that aim to mitigate correlation analysis by obfuscating 
packet sizes and timings, as they are generally consid¬ 
ered too costly to deploy (Appendix | A. 2| ). 


Taxonomy of Countermeasures 



1. Mitigating Traffic Interception 2. Mitigating Correlation Attacks 



Static Routing Routing Routing Symmetric Asymmetric 



Figure 15: Taxonomy of Countermeasures 


6.2 AS-Aware Path Selection 

To minimize opportunities for AS-level traffic analysis, 
the Tor network can monitor the path dynamics between 
the clients and the guard relays, and between the exit re¬ 
lays and the destinations. Information about path dynam¬ 
ics can be obtained using data-plane ( e.g ., traceroute) 
or control-plane (e.g., BGP feed) tools. For instance, 
each relay could publish the list of any ASes it used to 
reach each destination prefix in the last month. This in¬ 
formation can be distributed to all Tor clients as part of 
the Tor network consensus data. Tor clients can use this 
data in relay selection, perhaps in combination with their 
own traceroute measurements of the forward path to each 
guard relay. For example, Tor clients should select relays 
such that the same AS does not appear in both the first 
and the last segments, after taking path dynamics into 
account. 


Next, we consider two approaches for mitigating Rap¬ 
tor’s routing attacks: detection and prevention. 


6.3.1 Monitoring Framework for Detection Routing 
Attacks 

We propose that the Tor network monitor the routing 
control-plane and data-plane for robust detection of rout¬ 
ing attacks. Detecting routing attacks serves two pur¬ 
poses: (1) First, this serves to raise awareness about 
the problem and hold attackers accountable. (2) Sec¬ 
ond, Tor directory authorities can notify clients. Such 
notifications allow the end-user to respond by either sus¬ 
pending its use of Tor (since most hijacks and intercep¬ 
tions are short lived), or choose another Tor relay (see 
Appendix |A.1| for challenges and caveats for this ap¬ 
proach). Next, we discuss two proof-of-concept mon¬ 
itoring frameworks, based on BGP data and traceroute 
data respectively. 

BGP Monitoring Framework. Our BGP monitor¬ 
ing framework gathers BGP data from the Route views 
project. The framework filters BGP updates to consider 
data about prefixes that involve a Tor relay. Building 
upon prior work in routing attack detection [ 16]|, we im¬ 
plement the following heuristics. (1) Frequency heuris¬ 
tic: routing attacks can be characterized by an AS an¬ 
nouncing a path once (or extremely rarely) to a prefix that 
it does not own. The frequency heuristic detects attacks 
that exhibit this behavior. It measures the frequency of 
each AS that originates a given prefix; if the frequency 
is lower than a specified threshold, then it could be a po¬ 
tential hijack attack. (2) Time Heuristic. Most known 
attacks, including those discussed in §[5j last a relatively 
short amount of time. The time heuristic measures the 
amount of time each path to a prefix is announced for; 
if the amount of time is extremely small (below a speci¬ 
fied threshold), then there is the possibility of it being a 
routing attack. 

Detection Capability: We tested our BGP monitoring 
framework based on BGP data during known prefix hi¬ 
jack attacks, that were discussed in § [5] As a preliminary 
validation, the frequency and time heuristics were able to 
detect all of the known attacks; the threshold used for the 
frequency heuristic was .00001 and the threshold used 
for the time heuristic was .01. 

Traceroute Monitoring Framework. The BGP mon¬ 
itoring framework provides measurements of actual AS- 
level paths from BGP collector nodes. However, the in¬ 
put data to the monitoring framework is limited to peers 
who chose to participate in frameworks such as Route- 
views, and BGP data is only a noisy indicator of the rout¬ 
ing control-plane. For robust detection of attacks, it is 
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also necessary to monitor the data-plane, which we do 
via a Traceroute monitoring framework. 

Traceroute is a network diagnostic tool that infers the 
routers traversed by internet packets. To analyze both 
attacks and changes in AS-level paths to the Tor net¬ 
work, we have built a traceroute monitoring framework 
that runs traceroutes from 450 PlanetLab machines to all 
Tor entry and exit relays and stores the resulting tracer¬ 
oute data. The set of all Tor entry and exit relays is 
updated daily to accommodate new relays that have re¬ 
ceived the guard and exit flags. BGP hijack and inter¬ 
ception attacks typically affect a variety of users from 
different vantage points. Thus, traceroute measurements 
from 450 geographically diverse PlanetLab have the abil¬ 
ity to detect data-plane anomalies arising out of routing 
attacks. The PlanetLab machines are distributed across 
140 ASes. Meanwhile, the Tor entry relays are dis¬ 
tributed across 982 ASes and the exit relays are dis¬ 
tributed across 882 ASes. We use Team-Cymru (http: 
//www. team-cymru. org/) to compute the mapping be¬ 
tween an IP address and its autonomous system. We will 
make the data collected by our Traceroute monitoring 
framework available to the research community. 

Detection Capability: As a preliminary validation, our 
Traceroute monitoring framework was able to detect the 
the BGP interception attack discussed in § [3] From the 
traceroute data, we observed AS-level path changes from 
every PlanetLab node to our Tor guard relay, indicating 
an anomaly. 

6.3.2 Preventing Routing Attacks in Tor 

In addition to monitoring the routing control-plane and 
data-plane with respect to the Tor network, the following 
approaches can help prevent the threat of Raptor’s rout¬ 
ing attacks. 

Advertising /24 Tor prefixes: Our experimental mea¬ 
surements indicate that over 90% of Tor relays have a 
prefix length shorter than /24. This allows an AS-level 
adversary to launch a BGP hijack or interception attack 
against these Tor relays by advertising a more specific 
prefix for them (globally). We advocate that the Tor re¬ 
lay operators should be running Tor relays with a prefix 
length of /24. Autonomous systems typically filter route 
advertisements of prefix longer than /24, so AS-level ad¬ 
versaries will not be able to launch a more specific hijack 
or interception attack. 

Favoring closer guard relays: Even if a Tor relay adver¬ 
tises a /24 prefix, an AS-level adversary can launch an 
equally specific prefix hijack or interception attack (by 
advertising another /24). In this case, the impact of the 
attack is localized around the attacker’s autonomous sys¬ 
tem, since the route is not globally propagated. We advo¬ 
cate that Tor clients select their guard relays by favoring 


Tor relays with a shorter AS-level path between them. 
Tor clients could either obtain AS-level path information 
via the Tor network consensus download mechanism, or 
they can perform traceroutes themselves. This further 
mitigates the risk to Tor clients due to an equally specific 
prefix attack. We note that by selecting guard relays that 
are closer to the client in the AS topology, the risk of 
asymmetric traffic analysis and BGP chum is also miti- 
gated. 0 

Securing inter-domain routing: The research commu¬ 
nity has proposed multiple protocols for securing inter¬ 
domain routing ATI 32, 19,29, T71 Real-world deploy¬ 
ment of these protocols would mitigate the BGP hijack 
and interception attacks on Tor. However, this approach 
requires buy-in from multiple stakeholders in the com¬ 
plex ecosystem of the Internet, and progress on this front 
has been slow. We hope that the concerns we raise about 
the compromise of user anonymity in Tor can help accel¬ 
erate the momentum for improving BGP security. 

7 Discussion and Ethical Considerations 

Colluding adversaries. In this paper, we quantified the 
threat of Raptor attacks from the perspective of indi¬ 
vidual autonomous systems. In practice, autonomous 
systems can collude with each other to increase their 
capability of monitoring Tor traffic. For example, au¬ 
tonomous systems within the same legal jurisdiction may 
be forced to monitor Tor traffic and share it with a single 
entity that may launch Raptor attacks. 

Applicability to other anonymity systems. It is impor¬ 
tant to note that our attacks merely consider Tor as an 
example of a low-latency anonymity system. Raptor at¬ 
tacks are broadly applicable to other deployed anonymity 
systems such as I2P, Freenet and Tribler 17711211 [501 . 
Ethical considerations. We introduce and evaluate sev¬ 
eral novel attacks against the Tor network. The Tor net¬ 
work has a userbase of several million users (9), and 
these users are especially concerned about the privacy of 
their communications. Thus, it is of utmost importance 
that our real-world experiments on the Tor network do 
not compromise the privacy and safety of Tor users. In 
this paper, we take multiple precautions to safeguard the 
privacy of Tor users: 

• Attack our own traffic. All of our attacks only exper¬ 
iment with traffic that we created ourselves, i.e., we 
deanonymize our own traffic. In fact, we do not store 
or analyze traffic of any real Tor user. 

• Attack our own relay. Similarly, to demonstrate the 
threat of prefix interception attacks on the live Tor net- 

2 We note that if clients select closer guards, then knowledge of the 
guards reveals probabilistic information about the clients. We will in¬ 
vestigate this trade-off in future work. 


12 



work, we launch interception attacks against relays 
that we already control, i.e., we hijack/intercept our 
own prefix. 

• Firewall our Tor relay. We also used network-level 
firewalls to ensure that real Tor users will never use re¬ 
lays that we control: traffic from real users is dropped 
by the firewall. Only authorized traffic that we create 
ourselves can bypass the firewall and use our Tor relay. 

8 Related Work 

AS-level adversaries: It is well known that an adversary 
who can observe users’ communications at both ends 
of the segment can deanonymize Tor clients mm. 
Feamster and Dingledine were the first to consider the at¬ 
tack from the perspective of an AS-level adversary |28). 
Later, Edman and Syverson explored the impact of 
Tor path selection strategies on the security of the net¬ 
work l26l . Recently, Johnson et al. analyzed the secu¬ 
rity of the Tor network against AS-level adversaries in 
terms of user understandable metrics for anonymity El, 
and Akhoondi et al. E3 considered path selection algo¬ 
rithms that minimize opportunities for AS-level end-to- 
end traffic analysis. Finally, Murdoch et al. lf40l consid¬ 
ered the analogous analysis with respect to Internet ex¬ 
change level adversaries, which are also in a position to 
observe a significant fraction of Internet traffic. 

We build upon these works and introduce Raptor at¬ 
tacks, that leverage routing asymmetry, routing churn, 
and routing attacks to compromise user anonymity more 
effectively than previously thought possible. 

The attack observations in Raptor were briefly dis¬ 
cussed in a preliminary and short workshop paper [48]. 
In this paper, we go further by measuring the importance 
of the attacks using real-world Internet control- and data- 
plane data. We also demonstrate the attacks feasibility by 
performing them on the live Tor network —with success. 
Finally, we also describe efficient countermeasures to re¬ 
store a good level of anonymity. 

Traffic analysis of Tor: An important thread of re¬ 
search aims to perform traffic analysis of Tor commu¬ 
nications via side-channel information about Tor relays. 
Murdoch et al. l39l , Evans et al. [27], and Jansen et 
al. lf33] have demonstrated attacks that use node con¬ 
gestion and protocol-level details as a side channel to 
uncover Tor relays involved in anonymous paths. Fur¬ 
thermore, Mittal et al. |37] and Hopper et al. [ 30. 3L| 
proposed the use of network throughput and network la¬ 
tency as a side channel to fingerprint Tor relays involved 
in anonymous paths. We note that most of these attacks 
provide probabilistic information about Tor relays, and 
may not deanonymize the Tor clients. In contrast, Raptor 
attacks can completely deanonymize Tor clients. 


BGP insecurity: The networking research community 
has extensively studied attacks on inter-domain routing 
protocols including BGP hijack [ 5j] [52122 [44 ] and in¬ 
terception attacks ED. Similarly, there has been much 
work on proposing secure routing protocols that resist the 
above attacks However, we are the 

first to study the implications of these attacks on privacy 
technologies such as the Tor network. Arnbak et al. ED 
discuss surveillance capabilities of autonomous systems 
from a legal perspective, but do not discuss anonymity 
systems. 

9 Conclusion 

Raptor attacks exploit the dynamics of Internet routing 
(such as routing asymmetry, routing churn, and routing 
attacks) to enable an AS-level adversary to effectively 
compromise user anonymity. 

Our experimental results show that Raptor attacks 
present a serious threat to the security of anonymity sys¬ 
tems. Our key results include (1) demonstration of asym¬ 
metric traffic correlation on the live Tor network, which 
achieves 95% accuracy with no observed false positives, 
(2) quantifying the impact of routing asymmetry and 
routing churn on AS-level attacks - an increase of 50% to 
100% respectively compared to conventional attacks, (3) 
uncovering historical BGP hijacks involving Tor relays, 
and (4) successful demonstration of a traffic analysis at¬ 
tack via BGP interception on the live Tor network. We 
also outlined a taxonomy of countermeasures against our 
attacks. 

Our work highlights the dangers of abstracting net¬ 
work routing from the analysis of anonymity systems 
such as Tor, and motivates the design of next generation 
anonymity systems that resist Raptor. 
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A Appendix 

A.l Monitoring Challenges for Detecting 
Routing Attacks 

Detecting a malicious (or accidental) event, such as a 
prefix hijack or interception could be very helpful to a 
Tor user, but it also introduces a new possible attack. If 
users can select Tor relays that they know are not com¬ 
promised, then a clever attacker could hijack all Tor re¬ 
lays except for a few; then the user would be forced to 
use a small set of relays, which would be known to the 
attacker. While this vulnerability is introduced, our de¬ 
tection heuristics still bring accountability to the Tor net¬ 
work. Additionally, the Tor network can still use these 
detection mechanisms because of the short life span of 
hijack attacks; authorities can suspend the use of certain 
relays for a short amount of time, which should not sig¬ 
nificantly affect the Tor network. 

A difficult problem in hijack detection stems from 
the fundamental issues of BGP; many times events are 
flagged as suspicious, but in reality are a result of mul¬ 
tiple origin ASes, traffic engineering, or load-balancing. 
Prior research in the area of detecting prefix hijack and 
interception attacks had the primary goal of providing no 
false negatives and very few false positives; our goal is 
slightly different. We also have the goal of providing no 
false negatives, but false positives are less important; our 
goal is to increase anonymity over accuracy. This cou¬ 
pled with the ability to suspend relays for short periods 
of time (even for a false positive), should not cause harm, 
and should increase anonymity. 
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A.2 Rejected countermeasure: Mitigating 
Correlation Attacks 

Obfuscating packet timings and sizes: While the use 
of high latency mix networks (38J |23l and constant 
rate cover traffic [22] can mitigate timing analysis even 
against an adversary that observes all communications, 
these defenses are considered too costly to be deployed 
in the Tor network. 

Mitigating asymmetric attacks: Recall that our asym¬ 
metric correlation attack leverages information in the 
TCP header, namely the sequence number field that in¬ 
dicates the number of acknowledged bytes. One poten¬ 
tial countermeasure would be to encrypt the TCP header, 
by leveraging IP-layer encryption techniques such as IP- 
Sec. However, this approach introduces several chal¬ 
lenges. First, it would require a substantial engineer¬ 
ing effort to migrate Tor towards IPSEC. Second, since 
IPSEC is not widely used, this would make Tor traffic 
easy to distinguish from other encrypted traffic, thwart¬ 
ing its use for applications such as censorship resistance. 
Finally, encrypting the TCP header may not complete 
solve the attack. For example, an adversary could at¬ 
tempt to correlate TCP data packets with simply the 
number of TCP Ack packets, disregarding the sequence 
number field. 
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